C700 VST :: Battle of the Bits Lyceum

Guest L0 n00b

battle of the bits

Article History

Discussion

5906 views

102% doctorn0gloff

C700 VST

::|CONTENTS

Scope of this article
Quick setup
Capabilities
Configuration
Recording to .SPC/.SMC
See also
Appendix: List of MIDI CCs

The C700 VST is a VST plugin that emulates the Sony SPC700 (Nintendo S-SMP) sound chip from the SNES/Super Famicom.
The plugin was created by osoumen.

Notice! There now exists an extremely comprehensive guide to using C700 and its every ins and outs, written by our very own damifortune. You can check it out here!
That guide has all of what’s in this article plus a lot more, including advice on working with snes samples as well as using SNESMOD. This lyceum article will remain here if one wishes to read it, but for all snes-music-making needs, do head over to damifortune’s guide!

Scope of this article

This article is a guide to using the C700 VST to create hardware-compatible SNES SPC700 music (which means you can use this to create music for spc (format) compos in any tool/DAW that supports VST plugins!)

A lot of this and more technical information about C700 can also be found in the original documentation
, though there are many usage quirks and cool tricks that are either not on there, or deserve a clearer explanation.

Thus, this article is mostly intended as an expansion of the "Trick to Playing Well" section from the original developer docs; it will focus on the use of C700 in a DAW, effect usage, and other tips for getting a good .spc file out of your song.

Quick setup

Download here: C700 donload

On this page, you can find the downloads for the VST plugin itself, as well as an important add-on called playercode.bin which we will use to record and output .spc files.

Capabilities

Sample import: C700 is capable of loading samples (and their loop points) from .spc files, individual .brr sample files, as well as compatible .wav samples. A lot more detailed information on this can be found in the original docs
, but to do so, simply drag your file into the plugin interface with the corresponding sample slot in focus. (There are 128 sample slots, though realistically you shouldn't need that many.)

Sample export: C700 is also capable of exporting individual samples (for example, to save specific samples after importing a bulk set of samples from an .spc file) into either AddMusicK .brr format, or as a FastTracker instrument (.xi) file.

Note that when saving the sample as .brr, C700 will put a .smpl file in the same directory as the .brr file with the same name; this .smpl file contains metadata such as loop points and base pitch for C700 to use the next time you want to import that .brr file for use. It should always remain in the same directory as the corresponding .brr file!

MIDI-based playback: Being a VST plugin, C700 is compatible with a wide range of MIDI parameter control events. Each sample slot corresponds to a MIDI program/patch; it responds to all 16 MIDI channels and automatically allocates them to the 8 audio voices in the emulated SPC700 playback.
See Configuration for more.

.spc/.smc recording: The star of the show. That's right; in addition to allowing you to get authentic SNES sounds in your mixist projects, C700 can also export real .spc files, playable on real SNES hardware! (check out the c700 tag for entries made with this method). See the Recording to .SPC/.SMC section for more.

Configuration

To begin, add C700 to your DAW, set/find its MIDI IN port, and set up MIDI OUT instruments that output to that MIDI IN port.
Set these output channels to the MIDI channels 1-16 as you see fit. The MIDI patch/program number will correspond to the sample slot number in C700 (more or less; this depends on whether your DAW assigns patch 0 to NONE or Acoustic Grand Piano. Either way, Acoustic Grand Piano should correspond to C700 sample 0, and you can increment from there.)

How exactly this MIDI routing is done will depend on the DAW software that hosts C700; however, most anything that can host VSTs will also have proper MIDI routing so this should not be much of a problem.

MIDI control
C700 responds to MIDI control events the same way you'd expect any MIDI instrument to work.

Individual notes can have their own velocities; each MIDI channel has its own pan and pitch. You can automate/edit events for these in your DAW and C700 will respond (both during playback and also in the output .spc file it records.)

C700 also provides three "Velocity Curve" options, which change how MIDI note velocity (a value from 0-127) maps to the internal note velocity (and thus actual loudness during sample playback.)

C700 also responds to MIDI CC 1 (Modulation) for each channel; this controls a vibrato effect. The maximum vibrato depth (heard when MIDI CC 1 is set to max) and the global vibrato rate is set inside C700 with the Vib Depth and Vib Rate settings; this maximum vibrato depth as well as the vibrato rate is global for all channels.

To get portamento/note slides, you can either automate the pitch slides yourself using the pitch of each MIDI channel, or for a general portamento effect, you can enable the Glide toggle in the corresponding sample slot in C700. The Glide Rate setting in C700 has a large range; you should pull it up to about 50 or above to hear noticeable portamento.

Note that the Pitch Bend Range in C700 is a little odd; by default it is set to 2 which makes the host's maximum MIDI pitch bend only pitch up the output by 2 semitones. To get the full range of MIDI pitch bends (but with coarser resolution), set the C700 pitch bend range to 12.

These are only the most commonly-used and useful MIDI CCs that C700 can take; a full list of MIDI CC events that C700 recognizes can be found in the Appendix below.

Recording to .SPC/.SMC

To enable this feature, download playercode.bin from the donload page linked above, open the Set Recorder menu in C700, and drag the playercode.bin onto C700.

The important things to set here, other than song metadata, are the record start/end/loop points.
This will only work for VST hosts that send the playhead position to the VST plugin. Some non-DAW VST hosts do not support this properly (SAVIhost, for example, has its "playhead" start at 0 on VST startup and then indefinitely progresses the playhead without giving you any control over where it is.)

For DAWs that do support this, to set the loop points, place the playhead in the correct spot, and then click the Set button in the Set Recorder interface.

For large songs to be recorded to .spc, the apparent End point may cause the next loop to be a little delayed; this can be fixed by tweaking the End point back a few increments (shift by the smallest possible playhead increments allowed in your DAW for the best precision.)

When the "Save as .spc" or "Save as .smc" toggles are enabled, when playback reaches the Record Start point, C700 will start recording its playback to memory, and dump the resulting .spc/.smc to disk once it hits the designated Record End point.

This could mean pressing Play in your DAW and listening through your track until the Record End point, after which you'll see the .spc file on disk.

Alternatively, this can be fast-tracked by simply using your DAW to render the project (such as using a .mid export option), which does the playback and recording but much more quickly, without you having to wait for realtime playback.

Optimizing audio RAM usage
One important restriction of hardware-compatible SPC files is that the SPC700 chip only has access to a maximum of 64KB of audio RAM, which is shared by the music driver, samples, echo data, and song data.
This can get really cramped! Since .spc files recorded by C700 are simply recordings (much like .vgm logs), they cannot be as optimized as with tracker pattern-based conversion methods (like SNESMOD or XMSNES). Because of this, you have to be more mindful of memory usage, especially for large projects.

(Note that this 64KB limit is not an issue if you choose to export to .smc instead, which is now an accepted file format in spc (format) compos. An .smc file is a complete SNES game rom, which can't be played in spcplay/SPC-only emulations but must be played in a full SNES emulator such as bsnes or snes9x.)

C700 gives you some help with managing memory usage with the memory usage counter in the bottom right; this changes when adding new samples and changing the delay time. (Note that delay volume, delay filter, and toggling echo for samples do NOT change memory usage, so you can have as many delay-enabled samples as you like.)
This counter will turn red if the total space taken up by the driver, sample data, and the current echo settings exceeds 64KB; however, C700 will give no indication when the .spc it is recording in memory has run out of space during playback of song data; this can only be spotted during playback of the output .spc file, at which point you will hear the song suddenly halt and the last note played held indefinitely.

(Note that recent versions of C700 (as of Feb 2022) when out of .spc memory will actually export an .spc file alongside a script700 file (.700) file. The script700 file contains all the song data and the .spc file only contains the player code. This configuration is only playable through spcplay, and more importantly currently not supported in the SPC format on BotB! Do not attempt to submit the .spc file you get in this configuration (i.e. if you see an accompanying .700 file) as it contains no song data at all and cannot work as a standalone song when submitted.)

If you run out of memory while making your song (and because of this, it's prudent to test recording to .spc regularly while working on your project to know when to start being more conservative with memory use), there are a few protips to optimize how much memory your song data takes up.

Samples

Simply unload unused samples from C700; this saves a lot of space if you have large samples in your original .spc import, for example.

Delay time

A smaller delay time (ms) means less space is dedicated to echo data.

Parameter automation

DAW automations of MIDI control parameters correspond to more parameter-change commands in the song data, which take up more space; it's good to remove or mute automations whenever the channels they control are not heard in the song.

In addition, DAW automations often have very high resolution curves/envelopes for their values; each tiny change of a parameter takes up space, so aliasing your automations into more staircase-like envelopes will save a lot of space. Many DAWs have an option to either quantize the automation/event data into larger divisions, or turn an automation curve into a square/pulse/stair-stepped shape. This change is often not even noticeable at playback, so it's a good place to start when optimizing song data.

Note that CC1 vibrato is actually handled in this exact same way, in that each tiny pitch change of the vibrato is actually recorded as a separate DSP command in the song data, as opposed to a single "vibrato start" or "vibrato end" command like one might expect from tracker conversion methods. (For XMSNES or SNESMOD, the included sound driver offloads vibrato and other effects e.g. pitch bend to the CPU, which then controls the DSP during playback; C700's sound driver is by contrast extremely simple and merely plays back a series of recorded DSP commands from the .spc file and has no onboard effect processing.) This means that enabling vibrato will take up massive amounts of space in the .spc recording, and should be used extremely sparingly!

Velocity changes

Much like with .it modules, and for the same reason as above, each velocity change in a MIDI channel incurs a small memory cost in the .spc recording. Space can be saved by keeping the velocity constant for more consecutive notes in the MIDI data.

Managing voices
Because MIDI allows arbitrary polyphony yet the SPC700 can only play 8 voices at a time, C700 has some smarts to automatically allocate notes to voices. This usually works well for less dense music; however, once more denser polyphonic elements are added (such as a percussion layer, or thick chords), you can easily find yourself running up against the voice limit.

By default, C700 uses an Oldest Note-On allocation policy; voices are spread across channels as much as possible, and when the 8-voice limit is reached, the globally oldest note playing will be stopped and replaced by the incoming new note.
This can be changed by the VoiceAlloc setting in C700; the "SameCh" policy does the same thing but on the scale of each MIDI channel: new notes in a MIDI channel will only replace oldest notes from the same channel, so one channel never cuts out anything from another channel. This behavior is more like what a user would do when manually inputting notes in a tracker with 8 voices.

The priority of cutting notes out can be changed per-sample. Each sample has two priorities: one that is set at Note On, and one that is set at Note Release. This can be used to control how important a sample is compared to others while it is playing as well as after it has been released. The lower the priority, the more likely it will get cut by new notes.

You may also play with the "Mono" setting for each sample; this restricts a sample to playing only 1 note at a time, and coupled with the SameCh policy can result in quite compact monophonic instruments, though this tends to behave not predictably with other samples competing for the same voice. A lot of the time, not enabling Mono even for monophonic channels results in better voice allocation. Some testing and tweaking is called for!